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Mantenimiento del Software como Actividad de Ingenieria 


La definicién posiblemente mas utilizada de la Ingenieria del Software es la 
siguiente (IEEE, 1990)[footnote]: “La aplicacién de un enfoque sistematico, 
disciplinado y cuantificable al desarrollo, la operacion y el mantenimiento 
del software; esto es, la aplicacion de la ingenieria al software.” 

IEEE (1998) IEEE Std. 1219-1998, Standard for Software Maintenance, 
IEEE Computer Society Press, Los Alamitos, CA, 1998. 


En la propia definicién aparece el mantenimiento como una de las 
actividades de la Ingenieria del Software. Ahora bien ¢en qué se diferencia 
el mantenimiento de otras actividades de la Ingenieria del Software? — 
concretamente, ien qué se diferencia de lo que se suele denominar 
“desarrollo”?. Para clarificar esta delimitacion, hay que buscar un criterio 
que separe unas actividades de las otras. 


Como primera aproximacion, podemos decir que las actividades de 
mantenimiento del software son actividades de Ingenieria del Software 
orientadas a la modificaci6n o cambio del mismo (por diferentes motivos, 
que se verdn mas adelante). El cambio tiene como caracteristica 
fundamental el hecho de que primero se necesita una comprension del 
objeto que se ha de cambiar, para poder hacer efectiva la modificacién. Esto 
hace que la comprension del software como actividad humana, sea un 
elemento esencial en la Ingenieria del Software. Es decir, es conveniente 
que el software tenga una estructura y una documentacion asociada que 
facilite su comprension. 


La importancia del mantenimiento es de caracter econdmico — como toda 
actividad de Ingenieria. 


En un sistema que es facilmente mantenible, se puede implementar un 
cambio con un menor esfuerzo que en un sistema que es menos mantenible. 


Esto nos lleva a pensar que puede resultar rentable el hacer el software mas 
mantenible. Claro esta, esto solo sera asi si los cambios son frecuentes en el 
software. 


Todo software evoluciona para adaptarse a las necesidades de sus usuarios. 


La combinacion de los dos enunciados nos indica que es importante prever 
la mantenibilidad (es decir, la “facilidad de mantenimiento”), atin antes de 
la entrega del producto. 


El estado de la practica del mantenimiento del software 


Diferentes estudios han resaltado que el esfuerzo consumido en 
mantenimiento del software es en proporcion al tiempo de desarrollo, muy 
elevado, con cifras entre el 50% y el 80% dependiendo de los estudios. En 
cualquier caso, es claro que el mantenimiento es una actividad que consume 
muchos recursos. Las actividades de mantenimiento incluyen entre otros, 
los siguientes elementos: 


e Es necesario comprender el software y comprender los cambios que se 
deben realizar. 

e Es necesario modificar el software y actualizar la documentacion. 

e Es necesario volver a realizar las pruebas del software (prueba de 
regresion), ademas de probar especificamente las partes afadidas. 


Ademias de esos costes directos, hay costes ocultos que son de gran 
importancia, como: 


¢ oportunidades de desarrollo que se han de posponer o que se pierden, 
debido a que los recursos disponibles estan dedicados a las tareas de 
mantenimiento. 

e Insatisfaccion del cliente cuando no se puede atender en un tiempo 
aceptable una peticion de reparacion 0 modificacion que parece 
razonable. 

e Los errores ocultos introducidos al cambiar el software durante el 
mantenimiento reducen la calidad global del producto. 

e Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que 
dejarlos, total o parcialmente, para atender peticiones de 
mantenimiento. 


En 1970 ya se habia popularizado el término “Crisis del Software” para 
referir a la situacidn que acabamos de describir. Los sintomas de esta crisis 
han estado repercutiendo desde entonces en la industria de desarrollo de 


software y todavia se sienten sus efectos. Para resolver el problema surgi6 
un area de la informatica que recibe el nombre de Ingenieria del Software. 


Una de las principales causas de esta situacion ha sido la poca importancia 
que se le ha dado al proceso de Mantenimiento del Software 


El mantenimiento del software como un caso especial de 
mantenimiento 


El software no se deteriora con el uso ni con el paso del tiempo, a diferencia 
de los materiales mecanicos que son producto de otras actividades de 
ingenieria. Mejor dicho, no sufre de un deterioro fisico. No obstante, se 
suele considerar que el software tiene un deterioro en su estructura, cuando 
a lo largo del tiempo se van incluyendo mas y mas cambios que hacen que 
su estructura interna sea cada vez mas dificil de entender. En ocasiones se 
ha denominado a este fendmeno como “erosion del disefio”. 


Esta idea del deterioro de la estructura da lugar a la idea relacionada de la 
mantenibilidad. La mantenibilidad es una propiedad del diseno del software 
relativa a su facilidad de mantenimiento. Esto lleva a que en ocasiones se 
introduzcan cambios en el software solo para hacerlo mas mantenible, lo 
cual rara vez se encuentra en otras ramas de la ingenieria. 


Definiciones de Mantenimiento del Software 


El mantenimiento como actividad post-entrega 


Cualquier esfuerzo de Ingenieria del Software — si termina con éxito — 
acaba por producir un determinado producto software, orientado a satisfacer 
ciertos requisitos previamente establecidos. El mantenimiento en este 
contexto se entiende de manera general como las actividades de cambio de 
ese producto. Ahora bien, el cambio se puede entender de diferentes 
maneras. Comenzando por lo basico, la definicién de “Mantenimiento del 
Software” del estandar IEEE 1219 es: “El mantenimiento del software es la 
modificaci6n de un producto software después de la entrega para corregir 
fallos, para mejorar el rendimiento u otros atributos, o para adaptar el 
producto a un entorno modificado”. 


Esta definicién implica que las actividades de mantenimiento de un 
producto comienzan en el tiempo solo después de que el producto se ha 
entregado, es decir, después de que el producto esta en operacién. No 
obstante, en ocasiones se considera que algunas actividades de 
mantenimiento puede comenzar antes de la entrega del producto. 


Se puede considerar que ciertas actividades de mantenimiento comienzan 
antes de la entrega. Algunas de estas actividades son la planificacion de las 
actividades posteriores a la entrega, asi como toda actividad orientada a 
facilitar el mantenimiento, como la revision de la documentacion. No 
obstante, estas pueden considerarse actividades de preparacion para el 
mantenimiento, mas que de mantenimiento en si. 


Una vision mas amplia del mantenimiento del software 


Por ejemplo, Pigoski[footnote] (1997) resalta que hay una necesidad de 
comenzar a considerar el mantenimiento desde el mismo momento en que 
comienza el desarrollo: 

Pigoski, T. M. (1997) Practical Software Maintenance — Best Practices for 
Managing Your Software Investment. John Wiley & Sons, New York, NY. 


El mantenimiento del software es la totalidad de las actividades necesarias 
para proporcionar soporte econdmico (cost-effective) al sistema software. 
Estas actividades se desarrollan tanto antes como después de la entrega. Las 
actividades previas a la entrega incluyen la planificacion de las operaciones 
posteriores a la entrega, planificacion del soporte y determinacion de la 
logistica. Las actividades posteriores a la entrega incluyen la modificaci6n 
del software, la formacion de usuarios, y la operacion de un help desk. 


Como se ve, hay una diferenciacion en las diferentes definiciones entre 
actividades pre- y post- entrega del software. Para clarificar los conceptos, 
en esta obra diferenciaremos entre: 


1. actividades de mantenimiento propiamente dichas (posteriores a la 
entrega) y 
2. actividades de preparacion para el mantenimiento. 


El criterio para diferenciarlo de otras actividades es el hecho de la entrega 
del producto software. Se debe tener en cuenta que en ocasiones esa entrega 
es un acto formal dentro de un contrato, pero en muchas otras es una simple 
decision de disponibilidad publica de un grupo de desarrollo. Por ejemplo, 
en los proyectos de fuente abierto, desarrollados de manera voluntaria, el 
qué es una entrega lo determinan los propios desarrolladores cuando 
piensan que la funcionalidad implementada ha Ilegado a un determinado 
nivel. 


La guia SWEBOK[footnote] considera que el mantenimiento ocurre 
durante todo el ciclo de vida, y coincide en su definicion con la de Pigoski 
antes mencionada. 

www.swebok.org 


Es importante resaltar que el concepto de mantenimiento del software 
difiere de la concepcién de mantenimiento en otras disciplinas de 
ingenieria. Esto es debido a que el software no se “deteriora” con el uso. En 
la ingenieria mecanica, el mantenimiento consiste en las acciones de 
reparacion necesarias para que la maquina o sistema mecanico siga 
funcionando. En la Ingenieria del Software, el mantenimiento tiene un 
significado mas amplio, cubriendo su adaptaci6n a necesidades 


Evolucion del Software 


La evolucion del software 


E] término “evolucion” del software se utiliza desde los sesenta para 
denominar la dinamica de crecimiento del software. 


Una definicion atribuida a Lehman y Ramil dice que la evolucién del 
software es “todas las actividades de programacion que se orientan a 
generar una nueva version de un software a partir de una version anterior 
operativa. 


Ned Chapin [footnote ](1999) lo definid como “la aplicacién de las 
actividades y procesos de mantenimiento del software que generan una 
nueva version operative de un software con una funcionalidad de usuario o 
propiedades cambiadas a partir de una version anterior [...] junto con los 
procesos y actividades de garantia de calidad y con la gestion de esos 
procesos”. De estas definiciones se desprende que la evolucion cubre el 
ajuste a funcionalidades adicionales. 

Chapin, N., Hale, J.E., Khan, K.M., Ramil, J. and Tan, W. (2001) Types of 
software evolution and software maintenance. Journal of Software 
Maintenance and Evolution: research and practice, 13, pp. 3-30. 


La guia SWEBOK|[footnote] considera que la causa del mantenimiento esta 
tanto en la necesidad de “cambios” como de “evoluci6n” en el software. 
www.swebok.org 


Historia de la evolucion del software 


Durante los primeros afios de la era de la computadora, el software se 
contemplaba como un anadido. La programacion de computadoras era un 
"arte de andar por casa" para el que existian pocos métodos sistematicos. El 
desarrollo del software se realizaba virtualmente sin ninguna planificacion, 
hasta que los planes comenzaron a descalabrarse y los costes a correr. Los 
programadores trataban de hacer las cosas bien, y con un esfuerzo heroico, 
a menudo salian con éxito. El software se disehaba a medida para cada 
aplicacion y tenia una distribucion relativamente pequena. 


La mayoria del software se desarrollaba y era utilizado por la misma 
persona u organizacioOn. La misma persona lo escribia, lo ejecutaba y, si 
fallaba, lo depuraba. El disefio era un proceso implicito, realizado en la 
mente de alguien y, la documentaci6n normalmente no existia. 


La segunda era en la evolucion de los sistemas de computadora se 
extienden desde la mitad de la década de los sesenta hasta finales de los 
setenta. La multiprogramacion y los sistemas multiusuario introdujeron 
nuevos conceptos de interaccidn hombre - maquina. También se caracterizo 
por el establecimiento del software como producto y la llegada de las "casas 
del software". Los patronos de la industria, del gobierno y de la universidad 
se aprestaban a "desarrollar el mejor paquete de software" y ganar asi 
mucho dinero. 


La tercera era en la evolucion de los sistemas de computadora comenzo a 
mediados de los afios setenta y continuo mas alla de una década. El sistema 
distribuido, multiples computadoras, cada una ejecutando funciones 
concurrentes y comunicandose con alguna otra, increment6 notablemente la 
complejidad de los sistemas informaticos. Las redes de area local y de area 
global, las comunicaciones digitales de alto ancho de banda y la creciente 
demanda de acceso "instantaneo" a los datos, supusieron una fuerte presion 
sobre los desarrolladores del software. La conclusion de la tercera era se 
caracterizo por la llegada y amplio uso de los microprocesadores. El 
microprocesador ha producido un extenso grupo de productos inteligentes, 
desde automoviles hasta hornos microondas, desde robots industriales a 
equipos de diagnosticos de suero sanguineo. 


La cuarta era de la evoluci6n de los sistemas informaticos se aleja de las 
computadoras individuales y de los programas de computadoras, 
dirigiéndose al impacto colectivo de las computadoras y del software. 
Potentes maquinas personales controladas por sistemas operativos 
sofisticados, en redes globales y locales, acompafiadas por aplicaciones de 
software avanzadas se han convertido en la norma. 


La industria del software ya es la cuna de la economia del mundo. Las 
técnicas de la cuarta generaciOn para el desarrollo del software estan 
cambiando en la forma en que la comunidad del software construye 
programas informaticos. Las tecnologias orientadas a objetos estan 


desplazando rapidamente los enfoques de desarrollo de software mas 
convencionales en muchas areas de aplicaciones. 


Sin embargo, un conjunto de problemas relacionados con el software ha 
persistido a través de la evolucion de los sistemas basados en computadora, 
y estos problemas continian aumentando: 


1 


. Los avances del software continuan dejando atras nuestra habilidad de 


construir software para alcanzar el potencial del hardware. 


. Nuestra habilidad de construir nuevos programas no pueden ir al 


mismo ritmo de la demanda de nuevos programas, ni podemos 
construir programas lo suficientemente rapido como para cumplir las 
necesidades del mercado y de los negocios. 


. El uso extenso de computadoras ha hecho de la sociedad cada vez mas 


dependiente de la operacion fiable del software. Cuando el software 
falla, pueden ocurrir dafos econdmicos enormes y ocasionar 
sufrimiento humano. 


. Luchamos por construir software informatico que tengan fiabilidad y 


alta calidad. 


. Nuestra habilidad de soportar y mejorar los programas existentes se ve 


amenazada por disenos pobres y recursos inadecuados. 


En respuesta a estos problemas, las practicas de la Ingenieria del Software 
se estan adoptando en toda la industria. 


Leyes de la Evolucién del Software 


Lehman[footnote] (1974) formul6 las primeras “leyes de la evolucion del 
software” por primera vez a partir de un estudio del proceso de 
programacion en IBM. Con el tiempo, se han llegado a formular ocho de 
estas leyes. 

Lehman, M.M. (1974) Programs, Cities, Students, Limits to Growth?, 
Inaugural Lecture, May 1974. Publ. in Imp. Col of Sc. Tech. Inaug.| Lect. 
Ser., vol 9, 1970, 1974, pp. 211 - 229. Also in Programming Methodology, 
(D Gries ed.), Springer, Verlag, 1978, pp. 42 — 62 


En el ambito de ciencias de la ingenieria, una ley debe entenderse como una 
caracteristica comun a muchos fendmenos 0 que se presenta con 
regularidad. 


A continuacion se resume la formulacion de las leyes del mantenimiento tal 
y como se describen en (Lehman|[footnote], 1997). Todas ellas hacen 
referencias a programas “de tipo E”, es decir, a aquellos programas 
destinados a solucionar un problema del mundo real determinado: 

Lehman, M.M. (1997) Laws of Software Evolution Revisited, pos. pap., 
EWSPT96, Oct. 1996, LNCS 1149, Springer Verlag, 1997, pp. 108-124 


e Ley I: CAMBIO CONTINUO. 

e Ley Il: COMPLEJIDAD. 

e Ley III: AUTORREGULACION. 

e Ley IV: CONSERVACION DE LA ESTABILIDAD ORGANIZATIVA 
(VELOCIDAD DE TRABAJO INVARIANTE. 

e Ley V: CONSERVACION DE LA FAMILIARIDAD. 

e Ley VI: CRECIMIENTO CONTINUO. 

e Ley VI: CALIDAD DECRECIENTE. 


Estas leyes no son otra cosa que el resultado del estudio cientifico de 
experiencia acumulada en Ingenieria del Software. Como tales, nos pueden 
servir como base para la planificacion de las actividades de mantenimiento 
y para la toma de decisiones al respecto. 


Ley I: Cambio Continuo 


Un programa de tipo-E que se utiliza debe adaptarse continuamente, en 
caso contrario, el programa se hace progresivamente menos satisfactorio. 
Estas adaptaciones son el resultado del cambio en la operacion del entorno 
en el cual la aplicaci6n cumple una funcion. 


Ley II: Complejidad creciente 


A medida que evoluciona un programa, su complejidad se incremente, a 
menos que se trabaje para mantenerla o reducirla. 


Esta ley implica un tipo de “degradaci6n” o “entropia” en la estructura del 
programa. Esto a su vez implica un aumento progresivo del esfuerzo de 
mantenimiento, a menos que se realice algun tipo de mantenimiento 
perfectivo a este respecto. 


Ley III: Autorregulacion 


El proceso de evolucion del programa se autorregula con una distribucion 
de medidas de atributos de producto y procesos cercana a la normal. 


La evolucion de programas industriales tipo-E se lleva a cabo por un equipo 
que opera en una organizaciOn mas grande. Las decisiones de gestion 
respecto a los cambios en el programa constituyen una dinamica que 
determina las caracteristicas de crecimiento del producto. 


Ley IV: Conservacion de la estabilidad organizativa 


La velocidad de actividad global efectiva media en un sistema en evolucién 
es invariante a lo largo del ciclo de vida del producto. 


Usualmente se considera que el esfuerzo gastado en la evolucién del 
sistema se determina por decisiones de direccidn. Esto es por supuesto asi 
en un cierto grado, pero su influencia esta limitada por factores externos 
respecto al empleo, la disponibilidad de personal competente, etc. NO 
obstante, también influyen los atributos del sistema, por ejemplo, la 


complejidad. Los datos empiricos sugieren que la actividad lleva a una 
estabilizaci6n de actividad aproximadamente constante. 


Ley V: Conservacion de la familiaridad 


Durante la vida activa de un programa en evolucion, el contenido de las 
versiones sucesivas es estadisticamente invariante. 


Uno de los factores que determina el progreso de un desarrollo de software 
es la familiaridad de todos los implicados. Cuantos mas cambios y 
adiciones se hacen a una version, es mas dificil que todos los implicados la 
conozcan. Debido a que el crecimiento esta limitado por la capacidad de 
adquirir informacion de los participantes, una evolucién “grande” 
dificultaria ese aprendizaje, por lo que los cambios tienden a ser de un 
tamano parecido y limitado. 


Ley VI: Crecimiento continuo 


El contenido funciona de un programa debe incrementarse continuamente 
para mantener la satisfaccion del usuario durante su ciclo de vida. 


Esta ley refleja un aspecto del mismo fendmeno que refleja la primera. 
Habitualmente, los sistemas se crean con una limitacion en cuanto a la 
funcionalidad del dominio cubierta, por motivos de tiempo o recursos. Esto 
hace que con el tiempo, los requisitos que se descartaron vuelvan a aparecer 
como necesidades. 


Ley VII: Calidad decreciente 


Los programas de tipo-E seran percibidos como de calidad decreciente a 
menos que se mantengan de manera rigurosa y se adapten al entorno 
operativo cambiante. 


Esta percepcion de la calidad decreciente tiene que ver con los cambios en 
los criterios de aceptabilidad de los usuarios. 


Mantenimiento en el ciclo de vida del Software 


La guia SWEBOK|[footnote] considera el siguiente esquema de actividades 
para los cambios del software. 
www.swebok.org 


Solicitudes 
de Modificaciones 
Clasificar e 
Identificar —_» 
Entregar Analizar 
Aprobacion Disefiar 


Pruebas <<? Implementar 


Figura 1. Esquema de las actividades del Ciclo de Vida del Software 


El ciclo de vida del Software sigue el esquema de la figura anterior: en 
primer lugar los requisitos hay que clasificarlos e identificarlos para 
posteriormente analizar y poder disenarlos. Una vez hecho estos pasos, ya 
se puede implementar y a continuacion realizar las pruebas oportunas. Una 
vez realizada las pruebas y estas son validas, se entrega el software. Si se 
desea realizar una modificacion, este “requisito” debe de realizar el ciclo 
completo (clasificaci6n, identificaci6n, andlisis,.... ). 


Lo fundamental del esquema de actividades es que un cambio en el 
software sigue un “micro-ciclo” completo de ingenieria, al que debe 
preceder una actividad especifica de clasificacion, identificacién y toma de 
decisiones respecto a los cambios que por diversos motivos deben hacerse 
en el software. 


Tipos de Mantenimiento 


De la definicion de mantenimiento del estandar IEEE 1219 cabe distinguir 
tres causas fundamentales que desencadenan las actividades de 
mantenimiento. 


Las causas u origen de las actividades de mantenimiento del software 
pertenecen a tres grupos principales: 


1. Eliminacion de defectos del producto software. 
2. Adaptar el producto software a 
3. Incluir mejoras en el diseno. 


Las causas por tanto son todas ellas resultado de tener que modificar el 
software para que cumpla con los requisitos del usuario ya establecidos 
(caso 1), para que siga cumpliéndolos cuando cambia su entorno (caso 2), o 
cuando se quiere mejorar la manera en que los cumple (caso 3). 


Por otro lado, la definici6n anterior implica que el mantenimiento debido a 
los defectos es a posteriori, es decir, se desencadena cuando el defecto tiene 
como resultado un fallo que se detecta. En ocasiones, se realizan 
actividades de mantenimiento preventivo, que intentan detectar y corregir 
fallos latentes (que se supone pueden existir, aunque atin no se han 
“manifestado”). 


Estas causas tienen su correlacion directa con las denominadas “categorias 
de mantenimiento”, que en el estandar ISO/IEC 14764[footnote] incluye las 
siguientes categorias definidas por Lientz y Swanson [footnote ](1978) son: 
ISO/IEC (1999), ISO/IEC 14764, Software Engineering-Software 
Maintenance, ISO and IEC, 1999. 

Lientz, B.P. and Swanson, E.B. (1978). Characteristics of Application 
Software Maintenance. Communications of the ACM, June, 1978, pp. 466- 
471. 


1. Mantenimiento correctivo: modificaciones reactivas a un producto 
software hechas después de la entrega para corregir defectos 
descubiertos. 


2. Mantenimiento adaptativo: modificaci6én de un producto software 
realizada después de la entrega para permitir que un producto software 
siga pudiéndose utilizar en un entorno diferente. 

3. Mantenimiento perfectivo: modificacion de un producto software 
después de la entrega para mejorar el rendimiento o la mantenibilidad. 


Una consecuencia importante de las definiciones anteriores es que no se 
considera mantenimiento a los cambios introducidos para incluir nuevos 
requisitos funcionales. No obstante, no hay un consenso unanime en este 
sentido, y de hecho, el concepto de evolucion del software, que tratamos a 
continuacion, amplia el espectro del mantenimiento a cambios en un sentido 
amplio. De hecho, hay autores que consideran que el mantenimiento 
perfectivo si incluye cambios en la funcionalidad. De hecho, las categorias 
adaptativa y perfectiva son ambas mejoras, en contraposicion el 
mantenimiento correctivo. 


El estandar ISO/IEC 14764 clasifica las categorias comentadas hasta ahora 
segun la siguiente Tabla, que nos puede ayudar a ver sus diferencias. 


Correcci6n Mejora 
Proactiva Preventivo Perfectivo 
Reactiva Correctivo Adaptativo 


Por ultimo, un estandar de mantenimiento del IEEE (1998) define una 
categoria adicional, la de mantenimiento de emergencia, cuando los 
cambios se deben hacer sin planificaci6n previa, para mantener un sistema 
en operacion. 


Todas las anteriores definiciones son las que se encuentran habitualmente 
en los libros. No obstante, la clasificaci6n mas exhaustiva se encuentra en el 


articulo de Chapin (2001). 


Una visién mas general de los tipos de mantenimiento, se puede observar en 
la figura siguiente, ya que se distinguen los diferentes tipos de 
mantenimiento segun cambios de software, cambios de cédigo fuente o 


cambios de funcionalidad. 


i$ hicieron cambios al 
software? 


(Al) {Se utilize el software para iS cambio el cddizo fuente? 


fomnacion? Formacion 

(A2) j8¢ vtilizo para 
consultona? Consultona 
(A3) Se estudio? Evaluativo 


(Bl) Se maorola 
éocumentacion? Reformativo 
(B2) Se actuaiz la 
documentacion? Actualizativa 


(Cl) Sehizo al software mas 
mantenible? Mejorativo 

(C2) 8 eprepard para eviter 
mantenimiento ture? 
Preventive 

(C3) 28 ealtero el rendimiento 
del sistema? Rendimiento 
(C4) eadapto a otras 
tecnologias? Adaptativo 


Figura 1. Tipos de Mantenimiento 


jS2 cambio 41 codigo frente? 


(D1) :8e redujola 
fencionalidad? Reductivo 
(D2) :Se corrigio la 
fencionalidad? Correctivo 
(D3) :S afiadio o msjoro la 


fineionali dad? Adi tim 


